Many nodes (e.g., computing platforms, smartphones, or network devices) communicate data via messages, e.g., Internet protocol (IP) messages. Receiving nodes typically must parse, analyze, and/or decode header information stored in the messages to accurately process the messages. For example, a receiving node may attempt to identify a related message protocol associated with a message. A message protocol may define the content or form of a message in a standardized manner, so that entities using the protocol can communicate with each other unambiguously. A message may have distinct parts with distinct functions. For example, a message may include a routing header that identifies the sender and intended receiver of the message, a payload section that includes the content of the message that is to be delivered, and a checksum that may be used to detect and possibly correct errors that may have been injected into the message while in transit. These distinct parts are commonly referred to as information elements (IEs).
A message protocol may define several different varieties or types of messages. These message types may share some common IEs, such as the routing header or checksum, but may also have IEs that are unique to each type of message. For example, each message may include a message type identifier so that the receiving entity may unambiguously determine which type of message it is receiving and thus know what IEs that message should contain. For each type of message, the message protocol may define not only what IEs that type of message should contain but also what order that the IEs should appear within the message.
An entity that receives messages that adhere to a message protocol may use a programming construct called a protocol tree to parse the received messages. Protocol trees define one or more valid message formats. A familiar example is the hypertext transport protocol, or HTTP. HTTP defines a number of request types, including GET, PUT, POST, HEAD, DELETE, and TRACE. The following pseudo code represents the actions that might be taken by a parsing function that traverses an HTTP protocol tree that, for the sake of this example, is not optimally organized:
 1receive HTTP message; 2read HTTP message_type from the message type IE; 3IF message_type = TRACE THEN 4process TRACE message 5ELSE IF message_type = DELETE THEN 6process DELETE message 7ELSE IF message_type = HEAD THEN 8process HEAD message 9ELSE IF message_type = POST THEN10process POST message11ELSE IF message_type = PUT THEN12process PUT message13ELSE IF message_type = GET THEN14process GET message15END IF
In the pseudo code shown above, the parsing function traverses the protocol tree in the order in which the branches exist within the tree: the first branch defines the expected structure of a TRACE message, the second branch defines the expected structure of a DELETE message, and so on through the list of valid message types. If the most commonly received message type is the GET message, however, this means that for most messages the parsing function performs five separate and time consuming tests—TRACE, DELETE, HEAD, POST, and PUT—before it correctly matches GET. The efficiency of this parsing function could be improved by providing a new protocol tree whose first branch defines the expected structure of a GET message, whose second branch defines the expected message for the next most common message type, such as PUT for example, and so on. If the environment in which this parser and its improved protocol tree operates is one in which the least expected message type occurs the most often, however, the improved protocol tree suffers the same inefficiencies as before. In a conventional system that uses a protocol tree, the performance of the parsing function can vary greatly depending on the specific traffic received.
The example above illustrates the point that the order of IEs in a received protocol message could affect the performance of a decoding function if the order of IEs received doesn't match the order of the implemented protocol tree. These inefficiencies become more and more significant as the size of the protocol tree increases. Protocol trees that handle multiple protocols or protocols with many message types and/or significant variations of IEs within a message type can be quite large and are even more susceptible to this kind of inefficiency.
Accordingly, a need exists for methods, systems, and computer readable media for optimized message decoding.